Composing Requirements: Why Features Interact

ion configuration Chassis connects 4 wheels etc ... cost<60000 British Saloon Jaguar block valves Fig. 1. Structure and Re-Use can be con gured. [6] has examined the means by which feature requirements models can be built and validated by the client. This paper is concerned with the con guration issues. We show that the method by which we compose each feature with the standard telephone behaviour can help us to identify both the means by which features can be con gured and the potential interactions between features. Before we continue, there are three important issues which we must consider as a result of our compositional viewpoint | Composition Uniqueness: Is there always a unique set of components associated with a system requirements model? Con guration Uniqueness: Given a set of components of a requirements model, is there some one correct way of con guring the system. Compositional Detail: How do we know when the deconstruction of understanding should end? There are always di erent ways of understanding behaviour and such understanding leads to di erent sets of components. However, in the telephone model of requirements it is quite natural to view the system as a set of features. Certainly, di erent telphone users should be able to `see' the same set of feature components, and so we do not need to address the problem of composition uniqueness. The second question is the driving force behind the work being presented: given a set of feature requirements then how do we put them together into one requirements model? Di erent users will requires their features to work together in di erent ways | de ning di erent priorities between features, for example. Con guration is thus central to the feature interaction problem. The nal question is the bane of many an analysis process: too many systems are over-analysed leading to an increase in development costs and bad design. We do not address the problem directly in this paper but do specify some feature models October 3, 1997 DRAFT 4 compositionally. Thus, the feature is not the smallest building block in our models. The identi cation of a set of feature building blocks is an interesting problem [7] which is beyond the scope of this paper. With respect to analysis alone, it is accepted that there are many ways of structuring problem understanding. An analyst must chose the structure best suited to communicating the requirements model with the customer. As should be evident from the car example, we advocate an object oriented approach to requirements capture. B. Object oriented structuring Object oriented concepts were conceived in Simula [8], went through infancy in Smalltalk [9], [10] and could be said to be leaving adolescence, and approaching maturity, in the form of many di erent languages[11], [12], [13], [14], [15], [16] and methods[17], [18], [19], [11], [15], [20]. In each of these models, we see di erent forms of structuring which correspond to the ideas expressed in the car example. Certainly the exact semantics di er from model to model | this is one of the reasons why formal de nitions are so important | but, in general, each model provides each of these structuring facilities. In this paper we are concerned with con guration and so we could say that our presentation is object based[21]. The four main issues are summarised as follows: (1) Simple Composition Compositional structure is fundamental to object oriented analysis. A simple container view of composition enforces the notion of state encapsulation. The state of an object is de ned by the state of all its components. An object's state is encapsulated if it can be changed only through the services o ered at its external interface. Consequently, the state of its components can be changed only by the object itself. Composition is a relationship between a container object and its contained parts: It tells us nothing about the relationship between the parts. Con guration and interaction are two relationships which arise out of one object being decomposed into distinct parts. Two objects may con gure and interact only if they are components of a common container. (2) Con guration We view the con guration of components as an interdependency issue. Informally, two components con gure if at least one of the services provided by their containing object depends on both the components to ful l that service. This is a very abstract way of conceptualising con guration, but one which is appropriate to analysis. Con gurations lead us to de ne invariant properties between components that must be true for the containing system to behave correctly. In other words, invariants are part of the formal glue for putting requirements components together. (3) Dynamic vs Static Structure The notions of dynamic and static structure are important when attempting to provide an interpretation of composition properties. For the moment, we note that this paper presents an object based approach based on objects having static structure: objects whose internal composition and con guration may not October 3, 1997 DRAFT 5 change during execution. (Objects with dynamic structure are much more complex and, in our more general object oriented framework, they are speci ed using polymorphism and subclassing relationships.) (4) Sharing Finally, we must consider the complexities that arise when component parts are shared between systems. In this case we no longer have a simple container composition: the state of an object may change because a second object in the system changes the state of a component which it shares with the rst object. In fact, we shall see that such sharing is the source of many feature interactions. Sharing is a necessary part of systems of communicating components (like the telephone system) and so we need a means of controlling shared composition. From the user's point of view we propose to abstract away from shared network resources by using nondeterminism. This simple approach is appropriate for most of the features we have developed (see section 3). C. Requirements Modeling: Customer Orientation Requirements capture is the rst step in the process of meeting customer needs. Building and analysing a model of customer needs, with the intention of passing the result of such a process to system designers, is the least well understood aspect of software engineering. The process is required to ful l two very di erent needs: The customer must be convinced that requirements are completely understood and recorded, and the designer must be able to use the requirements to produce a structure around which an implementation can be developed and tested. In this paper, we concentrate on the customers' point of view, whilst noting that the object oriented approach does lend itself to meeting the designers' needs [22]. We advocate such a customer oriented approach since it is generally agreed that customer communication is the most important aspect of analysis [23], [24], [25]. The fundamental principle of requirements capture is the improvement of mutual understanding between customer and analyst, and the recording and validation of such an understanding in a structured model. The successful synthesis of a requirements model is dependent on being able to construct a system as the customer views the problem. [26], [6] illustrate this point with respect to feature models. D. Feature Interaction: What's new? A feature interaction is a situation in which system behaviour is speci ed as some set of features does not as a whole satisfy each of its component features individually. We concentrate on the domain of telephone features, where the problem has been acknowledged for many years [27], [28]. Figure 2 illustrates the problem within the formal framework which we adopt throughout this paper. We note that the means by which features are composed is not speci ed: it is the subject of the rest of the paper. Features are observable behaviour and are therefore a requirements speci cation problem [29]. Many feature interaction problems can be resolved through communication with the customer during requirements capture. Given a feature requirements speci cation which is not contradictory, interaction problems October 3, 1997 DRAFT 6 Informal Requirements Feature 1 (animator) dynamic validation formal model F1 property list P11,...,P1n verification static validation P1= Informal Requirements verification (animator) dynamic validation formal model F2 property list P21,...,P2n Feature 2 static validation P2= Interaction Definition Interact(F1,F2) iff F1 F2 Properties list P21, ... , P2m P11, ... , P1n P12 = verification Feature1 and Feature2 composition Model F12 F1 satisifes P1 and and F2 satisfies P2 not(F12 satisifies (P12)) Fig. 2. Feature Interaction: A formalisation during the design and implementation will arise only through errors in the re nement process. Certainly the feature interaction problem is more prone to the introduction of such errors because of the highly concurrent and distributed nature of the underlying implementation domain, but this is for consideration after each individual feature's requirements have been modelled and validated. We extend the work given in [6], where the composition of features was done in an ad-hoc fashion, by identifying and formalising re-usable composition mechanisms. The con guration of multiple features will be shown to depend on the way in which individual features are composed with POTS (plain old telephone service). Features are requirements modules and the units of incrementation as systems evolve. A telecom system is a set of features. Having features as the incremental units of development is the source of our complexity. An understanding of feature composition helps us manage the four main sources of this complexity | (1) State explosion: Potential feature interactions increase exponentially with the number of features in the system and traditional model checking techniques cannot cope with the complexity. The fundamental problem is that analysis cannot be done compositionally. We argue that compositional (re-usable) analysis depends on having a formal understanding of the composition mechanisms. This is the main goal of this work. (2) Chaotic Information Structure In Sequential Development Strategies: The arbitrary sequential ordering of feature development is what drives the internal structure of the resulting system. As each new feature is added the feature must potentially include details of how it is to be con gured with all the features already in the system. Consequently, to understand the behaviour of one feature, it is necessary to examine the speci cation of all the features in the system. All conceptual integrity is lost since the distribution of knowledge is potentially chaotic. At the moment this is certainly true. However, we believe that we can control the distribution of this con guration knowledge by containing it within a re-usable set of con guration mechanisms. (3) Implicit Assumption Problem: October 3, 1997 DRAFT 7 Already developed features often rely on assumptions which are no longer true when later features are conceived. Consequently, features may rely on contradictory (implicit) assumptions. This is a great source of interactions. We propose forcing the speci ers to formalise their (explicit) assumptions, by forcing them to use a certain set of con guration mechanisms. (4) Independent Development: Traditional approaches require a new feature developer to consider how the feature operates with all others already on the system. Consequently, we cannot concurrently develop new features: since how the new features work together will not be considered by either of the two independent feature developers. This problem is ampli ed if feature developers can con gure features in any way that they wish. We propose forcing developers to con gure systems in well de ned ways as a means of reducing the number of potential interactions. E. Feature Interaction: An incremental development view In gure 3, we take POTS as one requirement model. We note that to extend this base requirement with a new feature we must de ne a means of composing POTS with this feature, or, as illustrated in the diagram, use a previously de ned mechanism. Unfortunately, for two di erent features there is no guarantee that we can use the same composition mechanism. Furthermore, for each composition we may require an additional restriction (called the composition invariant) on the way in which the parts are con gured in order to gurantee that individual requirements are met. POTS POTS Feature1 Satisfies P and F1 iff Inv1(POTS,Feature1) where, Inv1 is an invariant of the composed system which is enforced by the composition mechanism comp1 comp1 Composition1 Composition2 Component Set Composition Set comp1 comp2 POTS + Feature2 Satisfies P and F2 iff Inv2(POTS,Feature2) where, Inv2 is an invariant of the composed system which is enforced by th composition mechanism comp2 Feature2 comp2 POTS RE-USE POTS + Feature1 Satisfies F2 Satisfies F1 Feature1 Feature2 Satisfies P Fig. 3. Incrementing POTS Given such a composition technique we must now address the problem of integrating Feature1 and Feature2 in the same set of requirements. In gure 4, we see that an interaction occurs if the invariants introduced by the two features and/or the two composition mechanisms are contradictory. We note that there are many di erent ways in which we may wish to compose the three components. The four most obvious structures are: October 3, 1997 DRAFT